In response to this:

What this PR does / why we need it

Adds a new --install-scope flag to the hypershift install command that controls which subset of manifests are applied:

• all (default): installs CRDs and resources (existing behavior, fully backwards compatible)
• crds: installs only CRDs
• resources: installs only resources (operator deployment and RBAC)

Why we need it

In ARO-HCP, the HyperShift Helm chart uses post-install hooks to run hypershift install. There's a race condition where the operator starts and creates a ClusterSizingConfiguration before the Helm hook can apply its own version, causing apply conflicts.

Splitting the install into phases allows:

1. CRDs to be installed first (--install-scope=crds)
2. CRD-dependent manifests (like ClusterSizingConfiguration) to be applied by Helm
3. The operator to start last (--install-scope=resources)

Which issue(s) this PR fixes

Fixes: https://redhat.atlassian.net/browse/AROSLSRE-1158
Related: https://redhat.atlassian.net/browse/AROSLSRE-313

Checklist

• Subject and description added to both, commit and PR.
• Relevant issues have been referenced.
• This change includes docs.
• This change includes unit tests.

Made with Cursor

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Walkthrough

This PR adds an InstallScope string to Options, validates it to allow only "", "all", "crds", or "resources", wires a new --install-scope CLI flag defaulting to "all", and changes InstallHyperShiftOperator to conditionally perform CRD dry-run/coordination/application and wait logic only when scope includes CRDs, and to apply operator resources and wait for deployment availability only when scope includes resources. It also adds Outputs.IsValid(), IncludesCRDs(), and IncludesResources(), removes the sets import, and updates ValidateRender to use Outputs.IsValid().

Sequence Diagram(s)

sequenceDiagram
  participant CLI
  participant InstallHyperShiftOperator
  participant ClusterCAPI
  participant KubernetesAPI
  participant Deployment

  CLI->>InstallHyperShiftOperator: call with InstallScope
  alt InstallScope == "all" or "crds"
    InstallHyperShiftOperator->>KubernetesAPI: perform CRD dry-run validation
    InstallHyperShiftOperator->>ClusterCAPI: detect/coordinate Cluster CAPI (unmanaged CRDs)
    InstallHyperShiftOperator->>KubernetesAPI: apply CRDs
    InstallHyperShiftOperator->>KubernetesAPI: waitUntilEstablished
  end
  alt InstallScope == "all" or "resources"
    InstallHyperShiftOperator->>KubernetesAPI: apply operator resources
    InstallHyperShiftOperator->>Deployment: WaitUntilAvailable
  end

❌ Failed checks (1 warning)

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

• X
• Mastodon
• Reddit
• LinkedIn

@@            Coverage Diff             @@
##             main    #8725      +/-   ##
==========================================
+ Coverage   41.59%   41.67%   +0.08%     
==========================================
  Files         758      758              
  Lines       93925    93949      +24     
==========================================
+ Hits        39066    39152      +86     
+ Misses      52113    52049      -64     
- Partials     2746     2748       +2     

... and 1 file with indirect coverage changes

Flags with carried forward coverage won't be shown. Click here to find out more.

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

The PR adds ~32 new executable lines inside InstallHyperShiftOperator() in cmd/install/install.go that restructure the CRD-apply and resource-apply logic into scope.IncludesCRDs() / scope.IncludesResources() conditional blocks. None of these lines are covered because:

1. InstallHyperShiftOperator() is never called from any test — confirmed by grepping install_test.go, which contains zero references to this function.
2. The function is inherently untestable as a unit — it immediately calls util.GetClient() to obtain a real Kubernetes client, then performs live cluster operations (dryRunValidateCRDs, apply, waitUntilEstablished, WaitUntilAvailable, isClusterAPIRegistered, etc.).
3. The flag registration line (cmd.PersistentFlags().StringVar(&opts.InstallScope, ...)) in NewCommand() is also uncovered since NewCommand() is not called in tests.

The ~15 covered lines come from install_render.go (the three new Outputs methods + the refactored render/validate logic) and the 2 validation lines in Validate(), which are well-exercised by TestRenderOutputsScope and the new TestOptions_Validate cases. But these ~17 covered lines out of ~49 total new executable lines yields only ~33-35% coverage, below the 41.59% target.

1. Extract the scope-filtering logic into a testable helper function. Move the "which manifests to install" decision out of InstallHyperShiftOperator() into a pure function like:

   func filterManifestsByScope(crds, objects []crclient.Object, scope Outputs) (crdsToDeploy, objectsToDeploy []crclient.Object) {
       if scope.IncludesCRDs() { crdsToDeploy = crds }
       if scope.IncludesResources() { objectsToDeploy = objects }
       return
   }

   This function can be unit tested trivially without a Kubernetes cluster, covering the branching logic that is currently uncovered.

2. Alternatively, increase coverage on the render side. Add test cases that exercise the error/default branches — e.g., test IsValid() with an empty string, test IncludesCRDs()/IncludesResources() with an invalid value — to push the covered line count up enough to cross the 41.59% threshold (need roughly 4-5 more covered lines).

3. Consider whether the codecov target is achievable for this kind of change. If the project policy is to maintain >41.59% patch coverage and the bulk of the change is in a function that requires a live cluster, the code needs to be restructured to separate pure logic from cluster-side-effecting code.